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Abstract 

As  the  U.S.  military  seeks  to  advance  its 
ability  to  perform  network-centric  operations, 
clearly  an  important  factor  is  improving 
interoperability  of  systems  of  all  types.  Since 
only  a  rare  system  operates  alone,  improving 
the  interoperability  of  networks  of  systems 
becomes  our  research  goal.  Many  non- 
homogeneous  networks  of  technological, 
human,  and  organizational  systems  are 
employed  in  all  types  of  military  operations. 
Within  DoD,  these  systems  and  their 
operational  uses  are  often  described  by 
Department  of  Defense  Architecture 
Framework  (DoDAF)  architectures  and 
include  system,  technical  and  operational 
views.  With  architecture  as  a  foundation,  a 
methodology  for  measuring  interoperability, 
called  an  “Interoperability  Score,”  is 
introduced.  The  methodology  first  defines  a 
baseline  measurement  of  interoperability  for  a 
non-homogeneous  network  of  systems  as  they 
are  used  within  an  operational  scenario  or 
“thread.”  The  methodology  then  defines  the 
theoretical  optimum  interoperability  score  and 
proposes  some  heuristics  which  can  be  used  to 
improve  overall  network  interoperability. 

Introduction 

The  past  decade  has  seen  a  focus  on 
interoperability  research  driven  by  a 
government  and  commercial  need  for 
improved  interoperability  of  systems.  Our 


research  shows  nearly  three  dozen  definitions 
of  interoperability  in  use  over  the  past  thirty 
years.  Within  the  past  decade,  it  has  been 
commonly  defined  as  “The  ability  of  systems, 
units,  or  forces  to  provide  services  to,  and 
accept  services  from  other  systems,  units  or 
forces  and  to  use  the  services  so  exchanged  to 
enable  them  to  operate  effectively  together.” 
(Amanowicz  and  Gajewski  1996),  (Curts  and 
Campbell  1999),  (Shelton  2000),  (Clark  and 
Moon  2001),  (Fewell  and  Clark  2003), 
(Kasunic  and  Anderson  2004).  Additionally, 
research  shows  that  many  over  the  past  decade 
have  proposed  interoperability  measures, 
notable  of  which  have  been:  1)  the  DoD 
Levels  of  Information  Systems 
Interoperability  (LISI)  model  (C4ISR  1998) 
which  was  recently  deleted  from  CJCSI 
62 12.0 ID  as  a  required  model  for  acquisition 
programs,  2)  the  Australian  Defence  Science 
and  Technology  Organization’s  LISI- 
extending  Operational  Interoperability  Model 
(OIM)  (Clark  &  Jones  1999)  and 
Organisational  Interoperability  Agility  Models 
(OIAM)  (Kingston,  Fewell,  and  Richer  2005), 
3)  the  Levels  of  Conceptual  Interoperability 
Model  (Tolk  &  Muguira  2003)  designed  to 
support  modelling  and  simulation  efforts,  4) 
the  Carnegie  Mellon  System  of  Systems 
Interoperability  (SoSI)  Model  (Morris,  et  al. 
2004)  which  addresses  the  programmatic 
impact  on  interoperability,  and  5)  the  Model 
for  Assessing  the  Performance  of 
Interoperable,  Complex  Systems  (Huynh  and 
Osmundson  2006)  designed  to  augment  a 
quantitative  vulnerability  assessment  model 
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(Gheorghe  and  Vamanu  2004).  With  the 
exception  of  the  Huynh  and  Osmundson 
model  which  simply  defines  an 
interoperability  measure  as  “the  mean  number 
of  elements  interoperable  with  [another] 
element  in  the  system,”  all  of  these  models  are 
more  qualitative  than  quantitative  and  were 
designed  as  a  means  of  attaching  a  label  or 
level  to  a  specific  type  of  interoperability  so 
that  systems,  networks,  operations,  and 
interactions  could  be  reported  and  compared. 

Mark  Kasunic  and  William  Anderson, 
noted  researchers  on  interoperability  at  the 
Carnegie  Mellon  Software  Engineering 
Institute,  aptly  recognize  that  “interoperability 
is  a  broad  and  complex  subject”  and  that 
“developing  and  applying  precise 
measurements...  is  difficult”  (Kasunic  & 
Anderson,  2004).  They,  however,  recognize 
that  “measuring,  assessing,  and  reporting 
interoperability  in  a  visible  way  is  essential  to 
setting  the  right  priorities.”  (Ibid).  To  this 
end,  our  research  proposes  the  i-Score  as  a 
generalized  measure  of  the  interoperability  of 
systems  of  all  types,  supporting  an  operational 
thread.  While  the  i-Score  methodology  can  be 
abused  by  making  improper  comparisons,  the 
i-Score  methodology  has  several  strengths 
including  1)  it  is  easily  computed,  2)  it  is 
based  upon  an  operational  thread,  3)  it  makes 
use  of  existing  architecture  data,  4)  it  can  be 
used  for  scenarios  where  one  or  more  type  of 
interoperability  is  represented  (i.e., 
information  and  organiztional 

interoperability),  5)  it  defines  the  optimum 
interoperability  for  a  given  operational  thread 
allowing  a  decision  maker  to  understand  what 
the  limits  of  his/her  interoperability 
improvements  are  and  what  can  realistically 
be  done  to  improve  interoperability  for  an 
operation  of  interest,  and  6)  it  provides  a 
means  of  drilling  down  into  a  process  to 
discover  where  interoperability  problems  lie. 


i-Score  Methodology 

Many  networks  of  non-homogenous 
systems  exist  and  are  described  by 
architecture  and  architecture  frameworks  (e.g., 
DoDAF,  Zachman,  TOGAF,  FEAF,  MoDAF, 
etc.)  which  include  various  views  including 
technical,  system  and  operational  views  which 
describe  how  the  systems  are  used.  The  i- 
Score  methodology  uses  this  existing 
architecture  data  (specifically,  DoDAF  OV-5, 
OV-2,  and  SV-3)  and  applies  graph, 
optimization,  and  interoperability  theory  to 
provide  a  generalized  measurement  of 
interoperability. 

The  i-Score  methodology  is  firmly  based 
upon  the  concepts  of  an  operational  thread  and 
an  interoperability  spin.  An  operational  thread 
is  defined  as  a  sequence  of  activities  where 
each  activity  is  supported  by  exactly  one 
system  (mechanism).  An  interoperability  spin 
is  defined  as  an  intrinsic  property  of  a  system 
pair  which  indicates  the  quality  of  the  pair’s 
interoperation.  Borrowing  from  physics,  spin 
is  a  quantized  intrinsic  property.  In  this 
research  paper,  we  use  the  word  spin  and  its 
connotation,  to  describe  the  intrinsic 
interoperability  between  two  systems,  i,j  and 
quantize  it  as  stJ  e  {-1,0, +1} . 

Our  goal  is  to  maximize  interoperability 
for  an  operational  thread  or  set  of  threads.  We 
want  to  penalize  our  interoperability  function 
when  system  pairs  need  translation  in  order  to 
interoperate,  and  reward  our  interoperability 
function  when  their  interoperation  requires  no 
translation. 

To  this  end,  the  best  spin  (+1)  is  assigned 
when  two  systems  can  communicate  without 
any  translation  (human  or  machine).  An 
example  of  a  system  pair  with  stj  =  +1  is  a  cell 

phone  and  a  cell  phone  tower.  The  next  best 
spin  (0)  is  assigned  to  a  system  pair  which 
requires  an  intervening  system  (non-human)  to 
do  a  machine  translation  to  allow  them  to 
interoperate.  An  example  of  a  system  pair 


with  Sy  =  0  is  two  cell  phones  (they  require 

the  cell  phone  tower  to  interoperate).  The 
worst  spin  (-1)  is  assigned  when  the  only  way 
for  two  systems  to  interoperate  is  if  a  human 
system  intervenes  and  translates.  An  stj  =  -1 

spin  is  often  assigned  between  two  human 
systems  when  they  require  a  third  human  to 
perform  language  translation  services  in  order 
for  them  to  communicate,  conduct  business,  or 
otherwise  interoperate. 

The  six  steps  in  the  i-Score  methodology 
are  presented  next. 

Step  1.  Diagram  the  operational  thread 
and  define  the  set  of  supporting  systems. 

Since  the  foundation  of  the  i-Score 
methodology  is  an  operational  thread,  it  is 
reasonable  to  begin  with  an  activity  model. 
IDEFO  or  UML  activity  diagrams  are  ideal 
because  they  require  no  modification  in  order 
to  implement  the  i-Score  methodology.  The 
DoDAF  OV-5,  the  functional  flow  block 
diagram,  the  N2  diagram,  or  IDEF3  diagrams 
can  also  be  used  with  slight  modification  in 
order  to  capture  the  system  supporting  each 
activity  in  the  operational  thread.  An 
example  IDEFO  activity  model  (DoDAF  2004) 
is  shown  in  Figure  1. 

Each  activity  in  the  operational  thread 
should  be  supported  by  at  most  one  system 
(mechanism).  Systems  (both  general  and 
specific)  can  be  technological  (e.g.,  PDAs, 
cell  phones,  trucks,  or  wrenches),  biological 
(e.g.,  human,  bacteria,  or  virus), 
organizational  (e.g.,  branch  office,  company, 
or  working  group),  or  environmental  (e.g., 
weather,  sun  spot  activity,  or  gravitational 
effects).  After  modelling  the  operational 
thread,  let  T  be  the  ordered  set  of  all  systems 
supporting  the  thread.  The  ordered  set  of 
supporting  systems  for  the  thread  in  Figure  1 
is  T  =  {  1,2, 2, 3, 4, 2}  where  Strategic  ISR  is 
system  #1,  Tactical  ISR  is  system  #2, 
Command  Authority  is  system  #3,  and 
Shooter  is  system  #4. 


Figure  1.  Sample  Operational  Thread 
(IDEFO) 


Step  2.  Create  an  interoperability 
matrix.  Fet  D  =  (V,E)  be  a  complete  directed 
multigraph  where  the  vertex  set 
V  =  {vl,v2,...vj  is  the  set  of  n  systems 
supporting  the  operational  thread  and  the  edge 
set  E  =  {e1,e2,...,enxJ  is  the  set  of  directed 
connections  between  systems  (including 
loops).  Note  that  n  *  |r|  if  a  system  supports 
more  than  one  activity.  Define  the  spin  matrix 
S  =  kl  >  sa  e{-l,0,+l},  —  as  a 

modified  adjacency  matrix  (similar  to  a 
DoDAF  SV-3)  representing  the  intrinsic  spins 
for  all  permutations  of  system  pairs  in  the 
operational  thread.  Define  the  multiplicity 
matrix  C  =  ["c,,.l  ,  c..  gD~°,  i,j  =  \...n  as  a 

matrix  of  spin  multiplicities  where  ci}  is  the 

number  of  times  a  system  pair  is  repeated 
when  the  elements  of  T  are  taken  two  at  a 
time  in  a  forward  direction.  Take  as  an 
example  the  operational  thread  in  Figure  1. 
The  set  of  systems  taken  two  at  a  time  is 
A  =  {(1,2),  (1,2),  (1,3),  (1,4),  (1,2),  (2, 2),  (2, 3),  (2, 4), 


(2, 2),  (2, 3),  (2, 4),  (2, 2),  (3, 4),  (3, 2),  (4, 2)} 
where  U I  = 


v2. 


.  Since  the  system  pair  (1,2) 


appears  three  times  in  A ,  then  cu-  3 .  At  this 
point,  it  is  appropriate  to  explain  why  the 
multiplicity  matrix  is  necessary.  A  system 
used  early  in  a  process  interacts  directly  with 
the  next  successive  system  in  the  thread,  but  it 


interacts  indirectly  with  every  successive 
system  in  the  thread  because  infonnation  it 
creates  or  transforms  is  eventually  passed  to 
successive  systems.  The  interoperability 
matrix  is  defined  as  M-\c..sA  .  Example 

L  lJ  lJ  Jnxn 

spin,  multiplicity,  and  interoperability 
matrices  for  the  operational  thread  in  Figure  1 
can  be  seen  in  Figure  2. 

“0  3  11]  [1-1-1  -f 

0322  -1  1  0  -1 

o  i  o  i  ’  s~  -1  -1  1  0 

0  1  0  oj  [-1-10  1 
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0  3  0  -2 

=>  M  — 

0-100 
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Figure  2.  Example  Multiplicity,  Spin,  and 
Interoperability  Matrices 

All  of  these  matrices  could  possibly  be 
extended  to  k  -dimensional  hypercubes  with 
additional  dimensions  representing  multiple 
links,  applications,  and  protocols  used  by  and 
between  systems.  A  look  at  layers  of 

interoperability  might  be  the  best  way  to 

analyze  this  type  of  k  -dimensional 
interoperability  matrix. 

Step  3.  Calculate  the  i-Score.  The  i- 

Score  is  an  objective  function  (Equation  1), 
which  we  will  later  seek  to  maximize  and 
represents  a  summation  of  spins  between  all 
system  pairs  along  the  operational  thread. 

n  n 

I=YLmu 

i= 1  j= 1 

Equation  1.  i-Score 

Step  4.  Determine  the  Optimum  i-Score. 

In  order  to  detennine  how  much  the 
interoperability  of  the  operational  thread  can 


be  improved,  we  need  to  know  the  optimum  i- 
Score  for  the  thread.  The  optimum  i-Score  is 
defined  as  the  maximum  possible  i-Score  in 
light  of  physical  and  operational  constraints. 
We  begin  be  recognizing  that  two 
systems  (/,_/)  are  perfectly  interoperable 
when  Sy  =+l.  Then  an  upper  bound  on  the  i- 
Score  occurs  when 

5 = [1L  => M = h  •  (+1)] = h  ]  •  But  this 

does  not  take  into  account  the  physical  and 
operational  constraints  mentioned  in  our 
definition  of  optimality.  We  need  to  know 
which  system  pair  spins  physically  or 
operationally  cannot  be  upgraded.  For 
example,  we  may  determine  that  in  light  of 
our  operational  thread,  we  want  system  i  and 
system  j  to  always  use  human  translation. 
Therefore,  their  spin  is  fixed  ats/;/  =-l.  Fet 

5*=[VL’  ^=maXK'}  Where  maX{5y}  is 

the  greatest  possible  spin  that  system  pair 
(i,j)  can  achieve  due  to  physical  and 
operational  constraints.  Then 

Mnn,  =  c„sH  I  is  the  maximally 

opt  |_  ,J  '•,L#=max{Si,.}_  J 

upgraded  interoperability  matrix  and  the 
optimal  i-Score  is  given  by  Equation  2. 

n  n 

IoP,=YLmij  I 
i=1  j=l  w.,„ 

Equation  2.  Optimum  i-Score 

Step  5.  Calculate  the  Interoperability 
Gap.  The  interoperability  gap  (Equation  3)  is 
a  measure  of  how  much  interoperability 
improvement  can  be  made  considering 
physical  and  operational  constraints  on  the 
operational  thread.  If  I  0 ,  then  various 

analysis  methods  can  be  used  to  determine 
how  to  shrink  Igap  . 

I  gap  -  1 opt  ~  I 

Equation  3.  Interoperability  Gap 


Step  6.  Perform  interoperability 
analysis.  Theoretically,  all  system  pairs 
whose  spin  is  not  +1  indicate  possible  areas 
for  interoperability  improvement.  A 
discussion  on  spin  upgrades,  use  of  common 
systems,  thread  comparisons,  and  thread 
concatenations  is  included  below  along  with  a 
network  interoperability  visualization  method, 
called  the  interoperability  terrain,  and  two 
techniques  (Average  Spin  and  Average  i- 
Score)  for  analyzing  an  interoperability  matrix 
irrespective  of  a  specific  thread. 

Spin  Upgrade.  One  of  the  simplest  ways 
to  analyze  an  operational  thread  for 
interoperability  improvement  is  by  examining 
individual  spins.  Let  A  =  {(/,/) :  ij  e  T)  be  the 
combinatorial  set  of  all  system  pairs 
supporting  the  operational  thread.  Let  F  a  A 
be  the  set  of  system  pairs  whose  spins  are 
fixed  and  cannot  be  upgraded.  Then 
F  =  {{i,j)\sj  upgradeable}  is  the  set  of  system 

pairs  whose  spins  can  be  improved  through 
methods  such  as  software  upgrades,  hardware 
changes,  new  company  policies,  or 
improvements  in  training.  Unfortunately, 
sometimes  no  means  of  spin  improvement  is 
readily  visible  (i.e.  F  -0).  In  these  cases,  it 
is  often  helpful  to  decompose  the  original 
operational  thread  down  to  a  lower  level  and 
then  re-compute  the  i-Score.  This 

decomposition  will  often  manifest  lower-level 
interoperability  problems  that  were  not  easily 
discovered  at  the  higher  level. 

Once  F  has  been  determined,  the  analyst 
might  wonder  which  system  pairs  to  upgrade 
first.  Cost  and  other  factors  aside,  it  is  better 
to  upgrade  the  systems  earlier  in  the 
operational  thread  because  their  improvements 
benefit  more  of  the  thread’s  activities.  To 
visualize  this,  take  a  five  system  thread 
T  =  {1,2, 3, 4, 5}  in  which  the  spin  matrix  is  the 
identity  matrix  (i.e.,  all  spins  are  zero  except 
for  the  diagonal).  If  we  upgrade 
interoperability  with  the  first  system  in  the 


thread  (s,.  =+l,  y  =  1...5),  we  get/  =  4,  if  the 
middle  system  is  upgraded  (s3j  =  +1,  j  =  1...5  ), 

we  get  1-2,  and  if  the  last  system  is 
upgraded  ( s5j  =  +1,  j  =  1. ..5  ),  we  get  /  =  0 . 

Using  Common  Systems.  Intuitively,  if 
the  same  system  can  be  used  to  support 
multiple  activities,  interoperability  should 
increase.  In  fact  it  doesn’t  matter  whether  the 
use  of  common  systems  occurs  at  the 
beginning,  middle,  or  end  of  the  thread — the 
resulting  i-Score  improvement  is  the  same. 

Operational  Thread  Comparisons.  At 

this  point,  the  analyst  should  be  cautioned 
regarding  i-Score  comparisons.  Just  because 
one  operational  thread  has  a  higher  i-Score 
than  another  doesn’t  mean  it  is  “better.”  Two 
operational  threads  which  accomplish  the 
same  mission  can  be  roughly  compared  by 
using  a  normalized  i-Score  (Equation  4)  which 
compensates  for  the  number  of  systems 
supporting  the  thread.  But  this  type  of 
comparison  is  not  always  appropriate.  The 
analyst  must  decide  whether  it  is  better  to 
upgrade  systems,  replace  systems  with 
common  systems,  or  keep  current  systems  but 
change  operational  uses.  The  i-Score  is  meant 
to  provide  a  generalized  starting  point  for 
discussion  regarding  interoperability 
improvement. 

-inn 

I  =— YYm 

norm  |^-,|  /  j  /  j  ij 

V  I  i=i  j= i 

Equation  4.  Normalized  i-Score 

Operational  Thread  Concatenations.  If 

more  than  one  operational  thread  is 
concatenated  together,  one  might  hope  that 
their  overall  i-Score  is  the  sum  of  their 
individual  i-Scores,  but  this  is  not  the  case. 
The  i-Score  of  the  new  combined  operational 
thread  must  be  calculated  anew  following  the 
steps  described  previously. 


Average  Spin.  The  average  spin 
/js  =£,y  is  a  rough  indicator  of  the 

S 

interoperability  of  the  network  of  systems 
irrespective  of  any  specific  thread. 

The  Interoperability  Terrain.  An 

interoperability  terrain  graph  can  be  used  to 
visualize  the  spins  in  a  network  and  can  help 
the  analyst  visualize  the  effort  required  for  the 
thread’s  systems  to  interoperate.  It  is 
analogous  to  a  hiking  route  overlaid  upon  a 
topological  map.  The  xy  plane  in  the 
interoperability  terrain  graph  is  a  system-to- 
system  plane  and  the  z  direction  indicates  the 
spin  of  the  system  pair.  An  example  of  an 
interoperability  terrain  graph  can  be  seen  in 
Figure  3  with  the  operational  thread  from 
Figure  1  overlaid. 


Step  1.  Define  the  Operational  Thread. 

Use  the  process  model  with  corresponding 
operational  thread  in  Figure  1 . 

Step  2.  Create  an  interoperability 
matrix.  Based  upon  the  operational  thread 
and  explanatory  information  (see  Appendix, 
Table  2),  the  multiplicity,  spin,  and 
interoperability  matrices  are  given  in  Figure  4. 
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Figure  3.  Interoperability  Terrain 
(Example) 


Average  i-Score.  An  average  i-Score  IN 
for  the  network  can  be  calculated  when 
multiple  inter-connecting  threads  are  of 
interest.  If  a  set  of  shortest  paths  between  all 
possible  system  pairs  is  calculated, 
recognizing  that  not  all  of  the  paths  are 
necessarily  operationally  feasible,  the  average 
of  the  normalized  i-Scores  associated  with  the 
threads  defined  by  those  paths  gives  a  general 
measure  of  whole  network  interoperability. 

An  Example 

At  this  point,  an  example  analysis  is  given 
to  illustrate  the  i-Score  methodology. 


Figure  4.  Multiplicity,  Spin,  and 
Interoperability  Matrices  for  Example 
Operational  Thread 

Step  3.  Calculate  the  i-Score.  Using 
Equation  1 ,  /  =  -6 . 

Step  4.  Determine  the  Optimum  i-Score. 

Setting  non-fixed  spins  at  their  operational 
and  physical  max  (see  Appendix,  Table  2),  the 
optimum  spin  and  interoperability  matrices  are 
given  in  Figure  5.  Using  Equation  2,  Iopt  =  4  . 
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Figure  5.  Optimal  Spin  and 
Interoperability  Matrices 
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Step  5.  Calculate  the  Interoperability 
Gap.  For  this  example, 

I gap  =IoP'-I  =  4~  (-6)  = 11 0  >  indicating 

substantial  room  for  improvement  in 
interoperability. 

Step  6.  Perform  Interoperability 
Analysis.  First  analysis  of  the  operational 
thread  is  undertaken.  For  our  example  thread, 
A  =  {(  1, 2),  (1, 3),  (1, 4),  (2, 2),  (2, 3),  (2, 4),  (3, 2),  (3, 4), 

(4.2) }  is  the  set  of  all  combinatorial  system 
pairs  supporting  the  operational  thread.  For 
illustrative  purposes,  F  =  {(1, 3),  (2, 2),  (2, 3), 

(3. 2) ,  (3, 4)}  is  the  set  of  system  pairs  whose 
spins  are  fixed,  and  F  =  {(1,2),  (1,4),  (2, 4),  (4, 2)} 
is  the  set  of  system  pairs  whose  spins  are  not 
fixed.  Then  four  spins  {snsu,s24,s42}  can  be 

improved  (see  Appendix,  Table  2). 
Operationally,  one  improvement  that  might  be 
useful  is  to  provide  a  live  Tactical  ISR  video 
or  radar  track  feed  to  the  Shooter.  This  could 
raise  the  spin  between  the  Tactical  ISR  and 
Shooter  systems  ( s24 )  from  -1  to  +1.  Since 
this  spin  has  multiplicity  c24  =  2 ,  this  spin 
upgrade  has  bang-for-the-buck  from  an 
interoperability  viewpoint.  This  one  spin 
upgrade  increases  I  -  -6  to  I  =  - 2 ,  a  big  step 
towards  closing  the  interoperability  gap 
(7  =  10  before  the  upgrade  vs.  7  =  6  after). 

Use  of  common  systems  yields  even  better 
improvement.  For  example,  if  the  Tactical 
ISR  system  is  an  unmanned  aerial  vehicle,  it 
may  be  possible  to  use  that  UAV  for  tactical 
ISR  and  as  a  shooter.  This  use  of  a  common 
system  for  multiple  functions  further  increases 
our  i-Score.  Analysis  of  the  entire  network 
yields  an  average  spin  for  the  network  of 
jus  =-0.3125  .  The  mean  and  variance  of  the 
interoperability  matrix  can  also  be  calculated. 
Results  of  the  interoperability  analysis  are 
tabulated  below. 


Table  1:  Analysis  of  Operational  Thread 


Measure 

M 

upgraded 

Mopt 

7 

-6 

-2 

4 

I  norm 

-0.4 

-0.133 

0.267 

Mm 

-0.375 

-0.125 

0.25 

1.583 

1.716 

1 

According  to  the  data  in  Table  1,  our 
starting  i-Score  for  our  operational  thread  was 
poor,  but  the  interoperability  gap  could  be 
decreased  by  40%  by  upgrading 
interoperability  between  the  Tactical  ISR  and 
Shooter  systems.  Better  improvement  in 
interoperability  comes  from  adding  Shooter 
capability  to  the  Tactical  ISR  system. 

Areas  for  Further  Research 

While  immediately  useful,  there  are 
several  areas  related  to  the  i-Score 
methodology  that  can  benefit  from  further 
research.  We  have  identified  some  of  these 
areas  as:  1)  How  can  we  account  for  decision 
logic  in  the  operational  thread  when 
computing  the  i-Score ?  2)  How  can  we  factor 
in  simultaneous  activity  in  operational  thread 
when  computing  the  i-Scorel  3)  Can  we 
compute  an  i-Score  when  multiple  systems 
support  one  activity  (i.e.,  multiple 
mechanisms  on  the  IDEFO  diagram)  without 
decomposing  the  activity?  4)  What  is  the  best 
way  to  use  the  i-Score  in  the  requirements 
definition  or  early  system  design  phases?  5) 
Can  the  i-Score  be  described  so  that 
interoperability  at  various  layers  (e.g., 
protocol,  application,  system,  organization) 
can  be  analyzed?  6)  Are  there  better  ways  to 
compare  i-Scoresl 

Conclusion 

This  research  investigated  an  architecture- 
based  method  of  measuring  interoperability  of 
complex  networks  of  non-homogeneous 
systems  called  the  i-Score.  It  uses  the 


operational  thread  as  its  foundation  and 
provides  a  single  number  measure  of  how  well 
the  systems  (technological,  biological, 
organizational,  and  environmental) 
interoperate  along  the  thread.  The  i-Score 
methodology  is  useful  not  just  to  those 
interesting  in  measuring,  analyzing,  reporting, 
and  improving  interoperability  of  technical 
systems,  but  is  applicable  to  any  situation  for 
which  an  activity  model  can  be  described.  As 
such,  the  i-Score  methodology  will  be 
especially  useful  to  policy-makers,  those 
interested  in  business  process  improvement, 
system  architects,  engineers,  as  well  as  a 
variety  of  others  interested  in  improving 
interoperability  of  their  network  of  systems. 
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Appendix 


Table  2:  Explanation  of  Example  Thread  Spins 


Spin 

Upgradeable?/ 
(Max  Spin) 

Rationale  for  Spin 

su  =  +1 

NO 

All  systems  have  perfect  interoperability  with  themselves 

^12  =  -1 

YES  (0) 

Strategic  ISR  can  only  communicate  with  Tactical  ISR 
through  a  human  (no  automated  cueing) 

S13  = 

NO 

Strategic  ISR  can  only  interoperate  with  the  Command 
Authority  through  a  human  (i.e.,  strategic  ISR  intelligence  is 
first  interpreted  by  a  human  and  then  passed  to  the 
command  authority) 

■*14  =  -1 

YES  (0) 

Strategic  ISR  intelligence  can  only  be  passed  to  the  Shooter 
through  a  human 

•*21  “  _1 

NO 

Tactical  ISR  intelligence  can  only  be  used  to  re-cue  the 
Strategic  ISR  system  through  human  intervention 

*23  =  0 

NO 

Tactical  ISR  intelligence  can  be  seen  directly  by  the 

Command  Authority  without  human  intervention  (i.e., 
Predator  video  feed). 

•*24  = 

YES  (+1) 

Tactical  ISR  intelligence  can  be  communicated  to  the 

Shooter  only  through  a  human-to-human  radio  call. 

■*31  = 

NO 

Command  Authority  can  re-cue  the  Strategic  ISR  system 
only  through  a  human  ground  station  operator. 

*32  “ 

NO 

Command  Authority  can  re-cue  the  Tactical  ISR  system 
only  through  a  human  operator. 

*34  =  0 

NO 

Command  Authority  can  pass  targeting  information 
machine-to-machine  to  the  Shooter. 

*41  =  ~1 

NO 

Shooter  can  request  re-cueing  of  the  Strategic  ISR  system, 
but  only  through  human  controllers. 

*42  = 

YES  (+1) 

Shooter  can  request  re-cueing  of  the  Tactical  ISR  system, 
but  only  through  human  controllers. 

*43  =  0 

NO 

Shooter  can  interoperate  directly  with  the  Command 

Authority  by  radio. 

